[PATCH 11/11] apparmor: fix race between freeing data and fs accessing it
authorJohn Johansen <john.johansen@canonical.com>
Mon, 2 Mar 2026 00:10:51 +0000 (16:10 -0800)
committerSalvatore Bonaccorso <carnil@debian.org>
Thu, 12 Mar 2026 12:28:10 +0000 (13:28 +0100)
commitc260bcfacdf94d19d9f96432d2d7ca3a69f6dc93
treecca60f1eb9e3491fec1c5b2e81df5bcadc6a91b3
parentff20961f3b3a75d990c2a69d5c8ff673df58d8f1
[PATCH 11/11] apparmor: fix race between freeing data and fs accessing it

AppArmor was putting the reference to i_private data on its end after
removing the original entry from the file system. However the inode
can and does live beyond that point and it is possible that some of
the fs call back functions will be invoked after the reference has
been put, which results in a race between freeing the data and
accessing it through the fs.

While the rawdata/loaddata is the most likely candidate to fail the
race, as it has the fewest references. If properly crafted it might be
possible to trigger a race for the other types stored in i_private.

Fix this by moving the put of i_private referenced data to the correct
place which is during inode eviction.

Fixes: c961ee5f21b20 ("apparmor: convert from securityfs to apparmorfs for policy ns files")
Reported-by: Qualys Security Advisory <qsa@qualys.com>
Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com>
Reviewed-by: Maxime Bélair <maxime.belair@canonical.com>
Reviewed-by: Cengiz Can <cengiz.can@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Gbp-Pq: Topic bugfix/all/qsa-2026-apparmor
Gbp-Pq: Name 0011-apparmor-fix-race-between-freeing-data-and-fs-access.patch
security/apparmor/apparmorfs.c
security/apparmor/include/label.h
security/apparmor/include/lib.h
security/apparmor/include/policy.h
security/apparmor/include/policy_unpack.h
security/apparmor/label.c
security/apparmor/policy_unpack.c